本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。
這次碰到師父是在清晨。我前一晚加班到天亮，回程買了早餐，到社區時剛好遇到交班。成哥戴著眼鏡，逐行看交接簿，停在一筆住戶反映的事項上。
成哥問：「這裡寫已通知，是通知誰？他怎麼回？」
師父指著前面的紀錄，說明聯絡過的對象，又把回覆補在旁邊。成哥確認今天需要再追一次，才繼續往下看。我沒有插話，等鑰匙、包裹和待辦都交清楚，師父提著袋子走出櫃台，才問他當 CTO 的事情。
「你不是主管嗎？怎麼我每次經過，還是看你自己寫程式、修東西？」
師父笑著問我，是不是覺得 CTO 應該整天開會、底下有一大群人。我說多少有這個印象，至少不會連每一個 bug 都自己處理。
師父解釋，CTO 通常指 Chief Technology Officer，但光看名稱，無法知道這間公司把哪些事情交給他。小團隊可能還沒有完整的工程分工，技術負責人得自己動手，也得和其他創辦人討論先做什麼。團隊大了，工作才可能更多放在組織、技術方向和協作方式上。
他拿兩種假設情況比較。如果團隊現在只有少數工程師，客戶連第一個完整流程都還用不起來，這時最急的可能是把問題定位、修好，讓人能試用。
另一間公司已經有多個產品和工程團隊，CTO 需要解決的可能是各團隊怎麼做共同決策、誰負責共用系統，以及重要技術投資要怎麼安排。
我問師父：「所以同樣叫 CTO，實際上可能是完全不同的工作？」
師父說，要一起看公司階段、團隊組成和決策權。職稱能提供一點線索，但問到這個人負責什麼結果、可以動用哪些資源，事情才會清楚。
師父用一個小團隊的早晨舉例：客戶說昨天的資料匯入失敗，工程師正在做新功能，創辦夥伴又希望下午能展示。這時技術負責人需要先知道故障影響誰、能不能恢復原有流程，以及展示是否必須調整。
我說：「那就是排優先順序。」
師父回答，排完還要有人承擔取捨。如果把兩個人都拉去修問題，新功能就可能延後；如果先用人工協助客戶完成這一次，也要知道人工處理會碰到哪些資料、由誰確認結果，不能只在群組裡喊一句先頂著。
我追問：「你自己寫最快的話，直接下去修不就好了？」
師父說，有時確實應該自己修。但如果每次遇到重要事情，都只有自己知道怎麼處理，就需要再看原因：是別人沒有權限、沒有足夠背景，還是自己一直沒有交出去？當主管的工作也包括讓團隊下次有能力接住，而不只是這一次做得比誰快。
成哥在櫃台裡接起電話。師父朝那邊看了一眼，確認是正常的住戶詢問，便繼續和我說。我們已經完成交班，成哥有自己的處理方式，不需要師父把每件事都接回去。
我問師父：「那如果其他創辦人答應客戶一個日期，你評估根本做不到，怎麼辦？CTO 可以直接說不算嗎？」
師父說，應該把可行的安排拿出來談。例如保留哪一部分可以在期限前完成，哪部分需要更多時間，以及硬做下去會影響什麼。最後採用哪個方案，也要讓負責對外承諾的人一起知道。
他補充，技術負責人需要參與會影響交付的決定。如果每次只在承諾已經做完後才被通知，卻又被要求對所有結果負責，那就得重新談合作方式。這和職稱大不大無關，而是責任與資訊、資源能不能接起來。
我說：「所以我問你管幾個人，其實還少問了很多。」
師父回答：「你也可以問，我能決定什麼。決定錯了，要跟誰說明。」
他接著說，早期公司不必為每件事設一層批准，但應該知道哪些決定可以由工程團隊完成，哪些涉及價格、客戶承諾、支出或公司方向，需要一起討論。人少可以溝通得快，卻不代表任何人都能替其他人無限答應。
我拿手上的早餐換了個位置，問師父現在下班以後是不是還得繼續做公司的事。他說每次安排不同，今天要先回去休息。我就沒有再追著他問日程。
理解 CTO 這個角色，可以從三個問題開始：
把這些問清楚，才知道寫程式、帶人和參與經營，在他的工作裡各占什麼位置。
成哥從櫃台後面抬頭，提醒師父袋子旁還有一條充電線。師父回去收好，朝我揮了揮手。
我也該回家睡了，這種血汗工作到天亮，真的該好好睡一整天 Q_Q
iThome鐵人賽
看影片追技術